Docket No. 0544MH-34056 


SPECIFICATION 


TO ALL WHOM IT MAY CONCERN: 

BE IT KNOWN that WE, Harri Rajala, Sami Lahti, Tapani Rautavirta, 
Samu Lahti, and Markus Salmi, have invented new and useful improvements in a 
METHOD AND APPARATUS FOR SUPPORTING MULTIPLE ALTERNATIVE 
GRAPHICAL USER INTERFACES IN COMPUTER-MODERATED ELECTRONIC 

COMMERCE 
of which the following is a specification: 
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BACKGROUND OF THE INVENTION 


2 

-3 1 . Field of the Invention: 

4 The present invention relates in general to computer-moderated methods of conducting 

5 commercial transactions, and in particular to graphical user interfaces utilized for electronic 

6 commerce. 

7 

8 2. Description of the Prior Art: 

9 There has been a sudden increase in the utilization of electronic commerce for the sale of 
10 goods and services. This is especially true with the explosion of activity related to Internet 
Jrl commerce, but is also true for commerce conducted utilizing distributed data processing 


j|l> systems which require a dial-in or other similar connection. A great amount of detailed 
|5 information can be provided to potential buyers over the Internet or a distributed data 
processing system. This gives the buyer a greater number of choices. And it also gives 
%$ the seller a greater number of opportunities and options for merchandising its goods or 


fi& Modern electronic commerce depends on a number of interchanges between potential 

19 buyers and sellers through a series of dialog boxes in cascading graphical user interfaces. 

20 Such graphical user interfaces include a variety of relatively conventional graphical 

21 components which are utilized to communicate the options which are available to the 

22 buyer, and to receive the buyer's selection. Typically, the options available to the potential 

23 customer are set forth in a manner which allows buttons to be depressed through 

24 manipulation of the graphical pointing device. In other words, most of the transaction 

25 "dialog" is conducted through the presentation of a series of options to the potential 


f6 services. 
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1 customer and a recordation of the customer's selection of the particular options through 

2 the use of a graphical pointing device. 


4 A variety of relatively well-known companies have relied heavily upon Internet-moderated 

5 commercial transactions. One leader in this area is Dell Computer Corporation of Round 

6 Rock, Texas. Dell has positioned itself well within the computer hardware market by 

7 relying extensively upon the Internet to conduct a relatively extensive dialog with potential 

8 customers, all moderated through a series of graphical user interface screens, which 

9 present the customer with a variety of options and choices. Through such reliance on the 
10 Internet, Dell has been able to keep its overhead low, turn its inventory often, and obtain 


p. good results for its shareholders in terms of marketshare growth, increased dividends, and 
^2 rapid increases in stock value. Dell is just one example of the increasing and highly 



effective use of the Internet to conduct commerce. 


For those engaged in electronic commerce, any means which can be utilized to further 


reduce costs and to stabilize operations will likely be appreciated and adopted. 


SUMMARY OF THE INVENTION 


It is one objective of the present invention to provide an improved method and apparatus 
for supporting multiple alternative graphical user interfaces in computer-moderated 
electronic commerce. 

It is another objective of the present invention to provide an improved method and 
apparatus for supporting a low bandwidth graphical user interface for use in computer- 
moderated electronic commerce. 

It is a particular objective of the present invention to provide an improved method and 
apparatus for supporting a low bandwidth HTML graphical user interface for use in 
computer-moderated electronic commerce. 

These and other objectives are achieved as is now described. 


1 BRIEF DESCRIPTION OF THE DRAWINGS 

2 

-3 The novel features of the present invention are set forth in the appended claims. The 

4 invention itself, however, as well as a preferred mode of use, further objectives and 

5 advantages thereof, will best be understood by reference to the following detailed 

6 description of the preferred embodiment when read in conjunction with the accompanying 

7 drawings, wherein: 
8 

9 Figure 1 is a simplified and pictorial representation of a distributed data processing 

.IP system; 

ft 

HI / 

Figure 2 is a simplified block diagram representation of an inside sales business object 


server; 


C£5 Figure 3 is a block diagram and pictorial representation of the scalability of the present 

U£ invention which represents one commercially advantageous product feature; 

figure 4 is a block diagram and pictorial representation of the multithread capability of the 

19 computer moderated electronic commerce system of the present invention which 

20 represents another commercially advantageous feature; 
21 

22 figure 5 is a block diagram and pictorial representation of an overview of the user 

23 interface options available utilizing the present invention which represents still another 

24 commercially advantageous product feature; 

25 

26 Pfgure 6 is a pictorial representation of an exemplary rule maintenance module; 
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2 Figure 7 is a pictorial representation of an exemplary dialog control screen in accordance 

( 

^3 with the present invention; 
4 

5 Figure 8 is a pictorial representation of an exemplary dialog manager screen in 

6 accordance with the present invention; 
7 

8 Figure 9 is a pictorial representation of an exemplary user interface maintenance 

9 operation in accordance with the present invention; 
10 

■igure 10 is an exemplary pictorial and block diagram representation of a plurality of user 
H> interfaces which may be supported utilizing the present invention; 

ft 

igure 11 is a flowchart representation of the utilization of a rendering engine to 
5L5 dynamically construct a series of graphical user interfaces, in real time, and utilizing a 
56 single database; 

& 

-igure 12 is a block diagram representation of the utilization of the present invention to 

19 support multiple alternative rendering engines from a single database which maintains 

20 metadata relating to the objects of the commercial transaction; 
21 

22 Figure 13 is a table of values used in conjunction with the preferred embodiment; 

23 

24 figure 1 4 is an example illustrating element layout in an HTML environment; 
25 
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Figure 15 depicts a populated HTML page in accordance with a preferred embodiment of 
frie present invention; and 

figure 16 is a flowchart illustrating an implementation of the preferred embodiment. 
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1 DETAILED DESCRIPTION OF THE INVENTION 

2 With reference now to the figures and in particular with reference to Figure 1 , there is 

3 depicted a pictorial representation of the Internet 106 and a distributed data processing 

4 system 108 either or both of which may be utilized to implement the method and system of 

5 the present invention. As may be seen, distributed data processing system 108 may 

6 include a plurality of networks, such as Local Area Networks (LAN) 110 and 132, each of 

7 which preferably includes a plurality of individual computers 112 and 130, respectively. Of 

8 course, those skilled in the art will appreciate that a plurality of Intelligent Work Stations 

9 (IWS) coupled to a host processor may be utilized for each such network. 
10 

|| As is common is such data processing systems, each individual computer may be coupled 

^ to a storage device 114 and/or a printer/output device 116. One or more such storage 

IB devices 114 may be utilized, to store the various data objects or documents which may be 

;f| periodically accessed and processed by a user within distributed data processing system 

%5 108. 

# Still referring to Figure 1, it may be seen that distributed data processing system 108 may 

i{8 also include multiple mainframe computers, such as mainframe computer 118, which may 

19 be preferably coupled to Local Area Network (LAN) 1 10 by means of communications link 

20 122. Mainframe computer 118 may also be coupled to a storage device 120 which may 

21 serve as remote storage for Local Area Network (LAN) 1 10. A second Local Area Network 

22 (LAN) 132 may be coupled to Local Area Network (LAN) 110 via communications 

23 controller 126 and communications link 134 to a gateway server 128. Gateway server 128 

24 is preferably an individual computer or Intelligent Work Station (IWS) which serves to link 

25 Local Area Network (LAN) 1 32 to Local Area Network (LAN) 1 1 0. 
26 
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1 As discussed above with respect to Local Area Network (LAN) 132 and Local Area 

2 Network (LAN) 1 10, a plurality of data processing procedures or documents may be stored 

3 within storage device 120 and controlled by mainframe computer 118, as Resource 

4 Manager or Library Service for the data processing procedures and documents thus 

5 stored. 
6 

7 Of course, those skilled in the art will appreciate that mainframe computer 118 may be 

8 located a great geographical distance from Local Area Network (LAN) 110 and similarly 

9 Local Area Network (LAN) 110 may be located a substantial distance from Local Area 
10 Network (LAN) 132. That is, for example, Local Area Network (LAN) 132 may be located 
U in California while Local Area Network (LAN) 110 may be located within Texas and 
p mainframe computer 118 may be located in New York. 

m •■ 

Figure 1 also shows a graphical representation of a connection between local area 

*P - 

*15 network 110 and the Internet 106 (World Wide Web) which is a wide area network 

*pb connecting thousands of disparate networks in industry, education, government, and 

l# 

0 research, which utilizes TCP/IP as the standard for transmitting information. As is shown 

: : c 

p in the view of Figure 1, a plurality of buyers (B1, B2, B3) may connect through the Internet 

19 106 to local area network 110 which, for purposes of explanation, represents a local area 

20 network under the control of a seller conducting electronic commerce. Alternatively, and 

21 simultaneously, a plurality of buyers (B4, B5, B6) may make a dial-in connection through 

22 gateway server 128 to local area network 110 in order to conduct electronic commerce 

23 with the seller which maintains control over local area network 110. The seller may utilize 

24 either or both the Internet connection or dial-in connection in order to communicate 

25 simultaneously with a number of buyers, including B1 , B2, B3, B4, B5, and/or B6. 
26 
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1 Figure 2 is a simplified block diagram representation of an inside sales business object 

2 server 202 which is connected via read/write bus 206 to sales data server 204. Sales 
'3 business object server 202 is composed of a number of software packages which are 

4 dedicated to particular electronic commerce functions. A read/write bus 206 allows sales 

5 business object server 202 to read data from sales data server 204, and also allows sales 

6 business object server 202 to write data to the sales data server 204. The sales business 

7 object server 202 includes a suite of server services modules 208 and a suite of data 

8 model modules 210. Preferably, the server services modules 208 include a session 

9 management module 212, a product data module 214, a document generator module 216, 
10 a pricing engine module 218, a configuration engine module 220, and a quote/shopping 
|| cart module 222. The session management module 212 is utilized to control the electronic 

dialog between each buyer or potential buyer and the seller and typically includes product 
names, product serial numbers, product descriptions, and product fact sheets as well as 


M 


% other similar information. The product data module 214 includes product information about 

*w 

the product array offered by the seller. The document generator module 216 is utilized to 

;fe generate printed materials which support the electronic transaction, such as shipping and 

;|7 invoice documentation. The pricing engine module 218 is utilized to allow the seller to 

i|& intelligently and accurately generate the total or "end" price to the customer. Preferably, 

19 the pricing engine module will take into account differences in currency, various discounts 

20 offered by the seller, the cost of freight and shipping, and the cost of warranties and 

21 extended service options. The configuration engine module 220 is utilized in order to at 

22 least partially automate a process through which the customer's needs are analyzed. 

23 Additionally, the configuration engine module is utilized to determine component 

24 compatibility in order to prevent the attempted combination of parts, components, or 

25 assemblies which are incompatible or not optimal. The quote/shopping cart module 222 is 

26 utilized to generate quotation documentation (both electronic and paper documents), if 
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1 necessary, and which builds automatically a quotation based upon configuration 

2 information, price information, and quote information. 

4 The data model modules 210 includes a plurality of software modules including a quote 

5 identification module 224, a quote version module 226, a configuration module 228, and a 

6 customer module 230. The quote identification module 224 is utilized to keep track of the 

7 identification of various quotes made to potential and actual customers. The quote version 

8 module 226 allows the system to keep track of a series of quotations to potential 

9 customers and actual customers in order to prevent inconsistencies between quotes, or 
10 other losses of information. The configuration module 228 maintains any information 
J} relating to particular potential or proposed configurations. The customer module 230 

if? 

jt? maintains customer information such as identity, address, telephone, payment method, 
and similar information. 

IP' 

H 

15 Collectively, the server services modules 208 and data model modules 210 cooperate to 

& allow orderly and efficient communication between the seller and potential buyers through 

ii* 

0 sales data server 204. 

19 Some advantages that may be obtained utilizing the present invention are graphically 

20 depicted in Figures 3 and 4. Figure 3 is a block diagram and pictorial representation of 

21 the scalability of the present invention which represents one commercially advantageous 

22 product feature, while Figure 4 is a block diagram and pictorial representation of the 

23 multithread capability of the computer moderated electronic commerce system of the 

24 present invention which represents another commercially advantageous feature. As 

25 depicted in Figure 3, a database server 240 may support a plurality of sales data servers, 

26 including sales data servers 204, 242. Each of the sales data servers 204, 242 may in 
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1 turn support a number of sales business object servers. For example, sales data server 

2 204 may support sales business object servers 244, 246, 248; additionally, sales data 
; 3 server 242 may support sales business object servers 250, 252, 254. In this manner, the 

4 computer moderated electronic commerce system of the present invention can be scaled 

5 in a pyramidal fashion which allows for a theoretically unlimited number of concurrent 

6 users being supported. 
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e computer moderated electronic commerce system of the present invention also allows 
simulraneous multithread operation, as is depicted in block diagram in pictorial form in 
Figure 4AAs is shown, a data server 260 may be utilized to allow database connection 
pooling. ThisNDptimizes the efficiency of database resource utilization. In the preferred 
embodiment, an oracle database may be utilized. The data server 260 provides the data 


|T3 to the application server layer which is composed of a number of separate components, 
M some of which were discussed above in connection with Figure 2. As is shown, sales 
45 data server 204 is communicatively and operationally coupled with sales business object 
server 202 which is capable of sbpporting a number of simultaneous electronic commerce 
communication sessions including sessions 270, 272, 274, 276. The sales business 
gt8 object server 202 is communicatively arqd operationally coupled to sales internet server 

19 280 which is in turn communicatively and operationally coupled to web server 282. Web 

20 server 282 allows for the simultaneous communication with potential buyers at and utilizing 

21 computing devices 290, 292, 294, 296, and 298. Essentially, sales business object server 

22 202 is a multithread server which utilizes multiprocessor servers. Multiple user sessions 

23 may be enabled in one process, which makes for efficient use of the operating system 

24 resources. The utilization of web server 282 and Internet^ales server 280 facilitates 

25 relatively low-cost simultaneous communication with buyers an^ potential buyers. The 

26 communication between web server 282 and the computers (290, 292, 294, 296, and 298) 
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1 which are under control of the buyers and potential buyers is conducted utilizing a 

2 relatively low bandwidth HTML dialog. 

4 In the prior art, companies that conducted electronic commerce did so utilizing a Windows- 

5 based graphical user interface which was accessed through conventional dial-in 

6 operations. The Windows-based graphical user interface typically communicated with a 

7 tabular database (such as a Sequel database). The bandwidth for communication 

8 between the Windows-based graphical user interface and the tabular database was 

9 relatively large in comparison with the bandwidth available for HTML-moderated 
10 communications via the Internet. As a practical manner, many entities that currently 

conduct electronic commerce have significant investment in non-Internet facilities including 
dial-up capabilities and Windows-based graphical user interfaces, as well as substantial 
investments in databases relating to the products, pricing, and customers. As electronic 
^ commerce migrates from dial-up sessions (where bandwidth presented no real problems) 
5L5 toward Internet-based communications (where bandwidth becomes a substantial problem) 
fjfc a significant number of problems must be resolved. Preferably, and in accordance with 
iW the present invention, an entity's investment in its electronic commerce systems need not 


In 


m 
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be wasted. In accordance with the present invention, a variety of graphical user interfaces 
may be constructed and maintained, without requiring reinvestment in, or recreation of, the 
databases which supported such electronic commerce. 

Figure 5 is a block diagram and pictorial representation of an overview of the interface 
options available uttozing the present invention which represents still another commercially 
advantageous product feature. The view of Figure 5 represents the different layers of 
processing which musnbe implemented in order to provide the system of the present 
invention. As is shown, \e data server 260 maintains the metadata which is utilized 

13 


during th^commercial transaction. This may include component identification and 
component property of the various Kerns offered for sale by the seller. The data server 
260 communicates\with the sales data server 204. The sales data server 204 
communications with the^ales business object server 202. The sales business object 
server 202 may communicat^Qver communication link 303 with data processing system 
296. The communication between the sales business object server 202 and data 
processing system 296 may be conducted utilizing the JAVA programming language; 
therefore, the client-user interface is supported by JAVA and communication is conducted 
over a local area network or a high speed wide > arfe^network. 


An alternative means of communicating with buyers is also provided. As is shown in 
Figute 5, sales internet server 280 may also communicate with sales business object 
server 2bz Web server 282 in turn communicates with sales internet server 280. Web 
server 282 communications intermittently over communication link 300 utilizing an HTTP 
protocol. Commfcmication is conducted with one or more data processing systems such as 
data processing system 290. Data processing system 290 is operating in a Web browser 
mode of operation. Comt^unication between data processing system 290 and Web server 
282 is conducted utilizing HTML. The communication link 300 is a low-speed wide-area 
network or internet connection. The view of 


Figure 5 shows two different user interfaces which are supported by the data maintained 


in data server 260. The dialog which makesvijp^the content of the electronic transaction is 
constructed dynamically by the sales data server 204 and sales business object server 


202 utilizing the metadata maintained on data seiver\260. In this way, a single data base 
may be utilized to support a plurality of simultaneous transaction dialogs in a plurality of 
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1 differing programming interfaces supported by different programming languages and over 

2 communication links wit\ different capabilities. 

£ 3 Figure 6 is a pictorial representation of an exemplary rule maintenance module. 

4 The content of the dialog may be maintained utilizing such a rule maintenance system 

5 which allows for the visual mapping of information. In this manner, the various 

6 components, sub-assemblies, and buyer options may be mapped out in a logical manner. 

7 The dialog between the seller and potential buyers may be constructed utilizing a "Dialog 

8 Control" module, which is depicted in Figure 7, and maybe manually generated utilizing a 

9 "Dialog Manager" module which is depicted in Figure 8. As is shown, the Dialog Control 
10 module in Figure 7 is utilized to enumerate the various dialog controls which are 

associated with a particular graphical interface screen. The example depicted in Figure 7 
relates to a dialog I.D. relating to the "chassis" of a vehicle. The seller may utilize the 
various command buttons on the right side of the screen to, add, delete, edit, clear the 
various controls which can be, or are, in fact, associated with a particular graphic user 
A5 interface. The Dialog Manager in Figure 8 depicts the dialog associated with a "cabin" 

M graphical user interface. As is shown, the dialog includes ListBoxl, ListBox3, CheckBoxl, 

I* 

£jl ListBox4, ListBox2, TextBoxl, CheckBox2, and PushButtonl. Each one of these 

jjs graphical user interface items has various "property" and "value" attributes associated 

19 therewith. Figure 9 depicts a number of simultaneously open and overlapping screens, 

20 including a Sales Maintenance screen which maps the relationship between the 

21 components, a Dialog Manager screen which lists the various dialog items associated with 

22 the "cabin" graphical user interface, and a Dialog Editor screen which is utilized to edit the 

23 Dialog Manager screen. Utilizing these functions, all of which are known in the prior art, 

24 one may construct graphical user interface screens which are logically linked to one 

25 another, which include a variety of dialog items, and which may be edited when product 

26 content changes. 
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Figure 10 is a pictorial and graphic representation of the maintenance of the various user 

~3 interfaces in accordance with the preferred embodiment of the present invention. As is 

4 showr\ a product rule set 310 is utilized to map or organize the various product features 

5 and options which are offered by the seller to potential buyers. The Dialog Controls 

6 module 312y is utilized to control the content of the dialog boxes of a graphical user 

7 interface. Thevcontent may be edited utilizing Dialog Editor 314. In accordance with the 

8 preferred embodiment of the present invention database 260 maintains the metadata 

9 associated with the product line and options which are set forth in the product rule set 310. 
10 Database 260 supports a variety of rendering engines which are utilized to generate 
|| graphical user interface\screens as part of the dialog transaction. As is shown, JAVA- 
jjj> rendering engine 320 accesses database 260 in order to generate dynamically and in real 

tf3 time user interface 326 which is a JAVA applet. HTML-rendering engine 322 utilizes 

& \ 

'pi database 260 to generate dynamically and in real time graphical user interface screen 328 

AS which is an HTML user interface. C++-rendering engine 324 utilizes data from database 

<p5 260 to generate dynamically and\in real time graphical user interface 330. Note that 

ig7 graphical user interfaces 326, 328, and 330 are all very similar in their content and layout, 

tfk even though they are generated in different operating environments utilizing different 

19 programming languages. All of the rendering engines 220, 222, and 224, make dynamic 

20 use of the Dialog Control box 312 in order to generate the graphical user interfaces 326, 

21 328, and 333. \^ 
22 

23 A method and apparatus is provided which allows for a single database to support 

24 dynamically a number of multiple alternative graphical user interfaces, all in order to allow 

25 computer moderated electronic commerce. The database interacts with a number of 

26 rendering engines which utilize metadata maintained in the database to dynamically 

16 
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1 generate an electronic commerce transaction dialog in a plurality of different 

2 communication, operation, and programming environments. For example, the present 
'3 invention may be utilized to simultaneously support graphical user interfaces constructed 

4 utilizing the programming language C++. Alternatively, and additionally, the system may 

5 support a graphical user interface constructed utilizing the JAVA programming language. 

6 Alternatively, and additionally, the invention allows a single database to support a relatively 

7 low band with communication in an internet environment utilizing the HTML programming 

8 language. In accordance with the present invention, the differing graphical user interfaces 

9 may have the same general appearance and the same series of dialog boxes in order to 
10 enable the electronic commerce. 


S 



Figure 11 is a flowchart representation of the utilization of a rendering engine to 
lynamtG 


dynamically construct a series of graphical user interfaces, in real time, and utilizing a 
single database. The process starts at block 402, and continues at block 404, wherein 
communication iSvestablished between a buyer and a seller. This communication will 
*p5 occur over a particulat^communication channel. For example, the buyer may make contact 
4JH7 with the seller utilizing the Internet by accessing the seller's website. Alternatively, the 
[§J buyer may dial-in to a wiaa area network utilizing conventional telecommunications 

19 modem connections in order to\ommunicate with the seller utilizing a graphical user 

20 interface constructed in the conventiohal manner utilizing the C++ programming language. 

21 Alternatively, the potential buyer may make communication with the seller utilizing JAVA 

22 applets. All three of these scenarios are alternatives to one another and are graphically 

23 depicted in Figure 10. In accordance with step\D6, the seller's data processing system 

24 activates the appropriate rendering engine which is\uited for the mode and channel of 

25 communication which has been established by the bifyer. For example, the buyer is 

26 making contact utilizing the Internet, the HTML rendering engine will be activated. Then, 
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1 in^accordance with step 408, the seller's data processing system calls the appropriate 

2 dialog manager module. In actual practice, an electronic transaction is composed of a 
'3 series^dfvcascading and logically-linked graphical user interfaces. Each graphical user 

4 interface has^associated with it a particular dialog manager module, as is conventional. 

5 The dialog manager module identifies each and every component of the graphical user 

6 interface which wilk^be presented to the buyer. Some of the components are "inactive" 

7 components and merely present images, data, or information; however, other elements of 

8 the graphical user interface are "active" elements which are adapted to receive user input 

9 typically through the detecticfi of the operator actuation of the graphical pointing device 

10 (typically the depression of the left button on the mouse associated with the buyer's 
jjj computer). Then, in accordance w^ith step 410, the seller's data processing system utilizes 
% the rendering engine to generate an associated graphical user interface. Concurrently 

with this step, and as is set forth in\tep 412, the data processing system of the seller 

$4 communicates with a single database inNprder to read metadata which is associated with 

45 the graphical user interface. As described above, the metadata may be arranged utilizing 
conventional tools such as a rule maintenance module. The metadata may comprise 
simple product number and feature information; however, in alternative electronic 

i§8 transactions, the metadata may comprise a substantial body of transaction and product 

19 information. The more complex the subject matter of the electronic transactions, the more 

20 likely there is to be associated with each graphical user interface a greater amount of 

21 detailed information. This communication between the \e^ndering engine and the single 

22 database is conducted in real time and is done so dynamically during the interaction 

23 between the seller's data processing system and the buyer^data processing system. 

24 One significant advantage of this approach is that the seller need not maintain multiple 

\ 

25 parallel databases for each rendering engine; instead, a single database may be 

26 maintained. This is a low cost option since there are greater coasts associated with 
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maintaining several parallel databases and it is often difficult to maintain consistency 
between such databases. 

InXaccordance with step 414, the data processing system under the control of the seller 
applies the metadata dynamically and in real time during creation of the graphical user 
interfae^ Then, in accordance with block 416, the seller's data processing system 
monitors for the dialog in order to determine input or selection of options by the buyer. In 
accordance\vith step 41 8, if necessary, the data processing system under the control of 
the seller is utilized to write data to the database. Then, in accordance with block 420, the 
rM) data processing system which is under the control of the seller monitors for a termination 
H of the communication session. If the session is ended, the process ends at block 422. 

?fjjz However, if the session is not ended, the data processing system under control of the 

ft? \ 

|p seller monitors the dialog^as conducted through the dialog boxes and returns to block 408, 

¥4 wherein the appropriate dialog monitor module is called based upon the buyer's input. The 

45 process repeats over and over again until the dialog is terminated. As a consequence of 

;|6 the dialog, a substantial amount of detailed metadata is sequentially presented to the 

•y \ 

W7 potential buyer in a series of cascading graphical user interface dialog boxes. In turn, the 

18 data and selections provided by the^buyer may be recorded to the single database in order 

19 to enable completion of the transaction or return to the transaction at a later date. It is 

20 widely known that many electronic interactions do not result in a transaction at the first 

21 contact. It may take several interactionkwith the buyer before a transaction is completed. 

22 This is the reason that most electronic transaction systems have shopping carts which 

23 may be preserved in memory and recalled at a later date by the buyer in order to allow the 

24 buyer to modify or add to the shopping cart. 
25 
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1 Figure 12 is a block diagram representation of the utilization of the present invention to 

2 support multiple alternative rendering engines from a single database which maintains 
^3 metadata relating to the objects of the commercial transaction. As is shown in Figure 12, 

4 the buyer system 500 communicates with a data processing system under control of the 

5 seller through communication channel 504. The communication channel may be a dial-in 

6 modem connection or an Internet connection. The mode of accessing the seller's data 

7 processing system will determine which particular one of a number of available alternative 

8 rendering engines are employed by the seller's data processing system. As is shown in 

9 Figure 12, rendering engines 506, 508, 510 may be utilized to support a variety of 
10 alternative communication modes. For example, if the various rendering engines may 
iil support communication through JAVA scripts, HTML protocols, or through a graphical user 

in 

Ifl2 interface constructed utilizing C++. Alternatively, other different programming languages 

r|3 and communication modes may be supported by different rendering engines. Once the 

,|4 appropriate rendering engine is selected, it communicates with a dialog manager module 

j|5 512. The dialog manager module communicates through rule maintenance module 518 to 

j f 6 database 520 which contains product metadata. The dialog manager modules correspond 

5|7 to various graphical user interfaces which are provide to the buyer's system 500 during a 

c l8 series of dialog box communications. The dialog manager module 512 is constructed 

19 utilizing a dialog editor 516 through available dialog controls 514. The rendering engine 

20 506 may pass information to database 512 for recordation. 
21 

22 Alternatively and/or concurrently, a number of buyers including buyers 502 and 522 may 

23 communicate through communication channels 524, 526 with alternative rendering 

24 engines including rendering engines 508, 510. These electronic transactions are 

25 communicated through a series of graphical user interfaces which present a series of 

26 dialog boxes to the buyer's system 502, 522 and which receive the input of the buyer and 
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1 selections of the buyer through monitoring the utilization of the graphical pointing device. 

2 Rendering engines 508, 510 also access database 520 through dialog manager 512 and 
'3 rule maintenance module 518. In this manner, a single database 520 is utilized to support 

4 a plurality of alternative rendering engines 506, 508, 510, which allow for simultaneous 

5 concurrent communication over different communication channels 504, 524, 526 with a 

6 plurality of buyer data processing systems 500, 502, 522. 
7 

8 The dialog editor 516 of Figure 12 is similar to a dialog editor utilized for creating and 

9 editing dialogs for the "rhythm" product of i2 Technologies, assignee of the present 
ifiO application. It includes many editing functions which allow a dialog to be either created or 
IfH edited. Such functions include the following specific functions: 

m 

rt2 • NEW : This command allows the programmer to create a new dialog box. 

■ W 

i|3 • OPEN : This command allows the programmer to open an existing dialog 

j?4 box template. 

|?5 • SAVE : This command allows a programmer to create a file for the current 

t 1 . 


JL6 dialog box template and save that template to the file, 

jf 7 • SAVE AS : This command allows the programmer to save the current dialog 

18 box template in a file under a new name. 

19 • TEST DIALOG : This command allows the programmer to toggle between a 

20 run mode in which the dialog box "comes alive" for testing purposes in an 

21 edit mode in which one can make changes to the dialog box. 

22 • CAPTURE DIALOG : This command allows the programmer to capture 

23 standard window controls from a standard window dialog box in another 

24 windows application. 

25 • EXIT : This command allows a programmer to close the dialog editor 

26 module. 
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1 • EXIT AND RETURN : This command allows a programmer to close a dialog 

2 editor and return to the host application. 

|3 • EDIT MENU : This command allows a programmer to undue up to ten 

-A preceding operations. 

5 • CUT : This command allows the programmer to select a dialog box control 

6 from an application window and place it on a clipboard. 

7 • COPY : This command allows the programmer to copy a selected dialog box 

8 control without removing it from the dialog editor's application window and 

I 

9 places it on a clipboard. 

10 • PASTE : This command allows the programmer to insert the contents of the 
clipboard into a dialog editor. 

m 

Lfp • CLEAR : This command removes a selected dialog box control from the 
programmer's application window without placing it on the clipboard. 

Jfjt • DUPLICATE : This command allows a programmer to create a duplicate 
copy of a selected control, 

J6 • SIZE TO TEXT : This command allows a programmer to adjust the board as 

fiz to certain controls to fit the text displayed on them. 

4$ • GRID : This command allows a programmer to display a grid dialog box 

19 which can be used to display or turn off the grid and adjust the grid spacing. 

20 The Dialog Editor 516 further includes a number of commands which are utilized to add 

21 control or communication elements to a particular user interface. Some principal control 

22 menu items include the following: 

23 • OK BUTTON : This command adds a default "OK" button to a dialog box. 

24 • CANCEL BUTTON : This command allows the programmer to add a default 

25 cancel button to a dialog box. 
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! 1 • HELP BUTTON : This command allows the programmer to add a help 

2 button to a dialog box. 

3 • PUSH BUTTON : This command allows the programmer to add a push or 

4 command button to a dialog box. 

5 • OPTION BUTTON : This command allows the programmer to add an option 

6 button to a dialog box. An option button is one of two or more link buttons 

7 that let user select only one from a group of mutually exclusive choices. 

8 • CHECK BOX : This command allows the programmer to add a check box to 

9 a dialog box. Users can check or clear a check box to indicate their 
^0 preference regarding the alternatives specified on the check box label. 

[|l • GROUP BOX : This adds a group box to a dialog box. A group box is a 
Jfc rectangular design element used to enclose a group of related controls. 

1 

; |3 One can use the optional group box label to display a title for the controls in 

#t the box. 

= 

Qb • TEXT : This command allows a programmer to add a text control to a dialog 
¥i6 box. A text control is a field containing text you want to display for the user's 

CJ7 information. The text in this field wraps, and the field can contain a 

18 maximum of 255 characters. Text controls can either display stand-alone 

19 text or be used as labels for text boxes, list boxes, combo boxes, drop list 

20 boxes, pictures, and picture buttons. One can choose the font in which the 

21 text appears. 

22 • TEXT BOX : This control allows the addition of a text box to a dialog box. A 

23 text box is a field in which users can enter text (potentially, as much as 32K). 

24 By default, this field holds a single line of non-wrapping text. If one chooses 

25 a multi-line setting in the text box,, this field will hold multiple lines of 

26 wrapping text. 
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1 • LIST BOX : This adds a list box to a dialog box. A list box is a displayed, 

2 scrollable list from which the user can select one item. 

)'3 • COMBO BOX : This adds a combo box to a dialog box. A combo box 

■4 consists of a text field with a displayed, scrollable list beneath it. Users can 

i< 5 either select an item from the list or enter the name of the desired item in the 

6 field text. The currently selected item is displayed in the field text. If the item 

7 was selected from the scrolling list, it is highlighted there as well. 

8 • DROP LIST BOX : This adds a drop list box to a dialog box. A drop list box 

9 consists of a field that displays the current selected item, followed by a 
10 downward-pointing error which users can click to temporarily display a 
yjfi scrolling list of items. Once they select an item from the list, the list 
Lft2 disappears and the newly selected item is displayed in the field. 

r|3 • PICTURE : This command adds a picture to a dialog box. A picture is a field 

.J4 used to display a windows bit map or metafile. 

Il5 • PICTURE BUTTON : This adds a picture button to a dialog box. A picture 

if 6 box is a special type of push, or command button on which a windows bit 

§7 map or metafile appears. 

up 

Cl8 • PICT TOOL : This enables a programming to select, move, and resize, items 

19 that control the insert point. 

20 The dialog editor of 516 can be considered to contain a pallet of functions, commands, 

21 and graphical elements which may be selected by a programmer in establishing the 

22 contents of a dialog which consists of one or more cascading or linked graphical user 

23 interfaces. The programmer utilizes the elements in the dialog editor in order to construct 

24 and edit a dialog. 
25 
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"h^dialog controls module 514 is comparable to a dialog controls module present in the 
"rhythm" product sold by i2 Technologies, Inc. Assignee of the present application. This 

*3 module\allows one to connect structure boxes to dialog controls one has created utilizing 

4 the dialog\ditor 516, An exemplary screen from the dialog controls module 514 of Figure 

5 12 is depictedvin Figure 7. As is shown, a "NAME 601" field is provided which displays the 

6 name of the actiye structure box. Additionally, a "CODE FIELD 603" is provided which 

7 displays the code olfva selected box. One can select another code from a drop down list. 

8 The boxes are listed irrttte same order as they appear in the structure. When a particular 

9 code is identified in Code^Box 603, a grid 605 is displayed there below which displays all 
10 dialogs, controls and variables that have been earlier designated as being associated with 

# the box or boxes. As shown in Figure 3, a grid 605 includes a variable field 607, a dialog 

US2 ID field 609 and a control field 611 . 

& x 

y§4 The same screen depicted in Figure 7 also depicts a series of fields which identify dialogs. 

i|5 A dialog name Box 613 is provided which identifies a particular dialog. A dialog ID box 

^6 615 displays a dialog ID that one has entered for a dialog in the dialog manager. A dialog 

~I7 control box 617 displays the dialog controls that have been created utilizing the dialog 

% editor 516 of Figure 12. 
19 

20 As is shown in Figure 7, a variety of control buttons are provided including an "OK" button, 

21 a "cancel button", "scrolling" buttons, a 'Variables" button which opens a variables dialog, a 

22 "clear" button which clears the PM variable from the selected control for the active box. An 

23 "add" button which can be utilized to add controls. A "delete" button which removes 

24 selected control from the active box, an "update" button which updates the active dialog 

25 and control as new ones in the grid, an "edit" button which opens the dialog manager 
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1 dialog, a "show" button which displays the dialog with the box codes attached to the 

2 controls, and a "close" button which closes the show dialog. 

.'3 

4 An exemplary screen from the dialog manager 512 of Figure 12 is depicted in the view of 

5 Figure 8. This dialog manager is similar to the dialog manager present in the 

6 "RHYTHMS" product of i2 Technologies which is the Assignee of the present application. 

7 The exemplary dialog manager screen includes an ID field 651 which displays the ID of 

8 the active dialog. A drop down list may be provided to allow the selection of another 

9 dialog. It further includes a name field 653 which displays the name of the active dialog. It 
10 contains a controls field which displays a list of controls related to the active dialog. The 
# controls are buttons, radio buttons, group boxes, etc. 

m 

fjp A properties grid 657 is also provided which contains the values from the dialog editor 

5 

y|4 established for graphical user interface elements. A plurality of control buttons are also 

fk5 provided in the view of Figure 8. A programmer may create a new dialog by clicking the 

J6 "ADD" button. The programmer may create a new dialog by clicking the "DLG EDITOR" 

3f7 button. The scrolling buttons are provided to allow backwards and forwards scrolling. A 

% "SAVE" button is provided to allow the saving of a edited or newly created dialog. The 

19 "DELETE" button allows the deletion of an active dialog. 

20 

J2J? Figure 13 is a table which identifies the primary values which are under the parameters 

(22 control. aV'CLASS" value cannot be edited. However, the X and Y coordinates may be 

23 edited. These X and Y coordinates establish an X and Y coordinate in pixels for a 

24 graphical useV interface element. The Y variable displays the width of the control element 

25 in pixels and the value H displays the height of the control element in pixels. The TITLE' 

26 element is a fielqfor displaying the title of the control. The "OPTION" group cannot be 
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1 edited. The 'TEXT' element identifies a default static control text. The "FONT element 

2 establishes^ font name, size, and style. The "MULTI-LINE" element identifies an edit 

3 control featureNn which a multiple or single line text may be identified. The "RTF' and 

4 "RTF TOOLBAR" etements identify a text box that can contain RTF text (Microsoft's rich 

5 text format). The "EXTENDED" element identifies a multi-select list box that includes a 

6 check box for items in thatylist box. 
7 

8 Determining the relative position of all of the elements in a graphical user interface is a 

9 relatively simply matter when the operating environment and language is suitable for 
10 relatively high-bandwidth communication. For example, graphical user interfaces encoded 
JB1 in C++ or JAVA are relatively easy to implement using the present invention. However, 
^2 graphical user interfaces which utilize HTML are a little more complicated to implement 
|3 since there is no X.Y (coordinate system) in an HTML environment. In accordance with 

one implementation of the present invention, the elements of a graphical user interface 

a A5 may be located in HTML tables which can be utilized to emulate an X, Y coordinate 

^6 system and which can be utilized in real time to properly locate the user interface 

j|7 elements. When operating an HTML environment, the present invention allows an HTML 

C}8 page to resemble graphical interface layouts for alternative rendering engines such as 

19 C++ and JAVA, utilizing a single database. Accordingly, the present invention allows a 

20 single database to support multiple user interface environments so separate parallel 

21 databases need not be maintained. 
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Figure 14 is a pictorial representation of how elements in a graphical user interface in an 
4 HTML environment are laid-out in accordance with the preferred embodiment of the 

25 present invention. Vs is shown, HTML page 400 is divided up into segments which cover 

26 the entire space that\s available. In the HTML format, this is considered to be a irregular 

27 
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•1 tableX The space within HTML page 700 will be accounted by a "cell" within the table even 

2 if there\is no text or image provided in that particular portion of Page 700. In the view of 

-3 Figure T^, "cells" which do not contain any text or images are shown in dashed outlined 

4 form. Portions of the graphical interface which include text or images are shown in solid 

5 line form. The space within HTML page 700 may be divided up into rows. The first row is 

6 made up of cejls 701 , 703, 705, 707. Of these, cell 707 does not include any text or image 

7 portions. It is merely space which is not utilized. The cell 707 is utilized by the program in 

8 order to "accounAfor the space. The second row includes cells 709, 71 1 , and the upper 

9 portion of cell 713.\Cell 711 does not contain any text or images and is utilized merely to 
10 account for the space between cell 709 and cell 713. The third row is made up of cells 
Jl 715, 717, 719, 721, and 713. Of these, cells 715, 721 are regions which do not contain 
ijj2 any text or images andy/vhich are utilized only to account for the space in that row. The 

Lii \ 

j|3 > next row includes cells 723, 725, 727, 729, 731 . Cells 725, 729 include text and/or images 

Jjj* while cells 723, 727, 73l\do not include any text or images and are merely utilized to 

S ? 15 account for the space in that row. This row also includes the portion of cell 713. The next 

^6 row is made of cells 733, 735\ 737, 739, 741, 713. Of these cells, cells 733, 737, 741 are 

#7 not utilized for depicting any text or images and are merely utilized to account for the 

£§8 space in that row. The next row includes cells 743, 745, 747, 749, 751 and 713. Cells 

19 745, 749, 713 include text and/^>r images. Cells 743, 747, 751 do not include text or 

20 images. The next row includes cells 753, 755, 757. Cells 755, 757 include text and/or 

21 images while cell 753 does not include any text or images. The final row is made of cell 

22 759. \ 
23 

24 Figure 15 depicts HTML page 15 with cells populated with text and images in accordance 

25 with the Dialog Controls 514 and Dialog Manager 512 of Figure 12. As is shown, cell 701, 

26 703, 705 include textual material. Cell 71 3 includes a photo of the product. Cells 709, 
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1 717, 719 include textual material relating to product features. Cell 725, 735, 745, 729, 

2 739, 749 include active areas which receive operator selections. Cell 755, 757 include 
"3 buttons. Cell 759 includes scroll back and log out text. Examination of Figures 14 and 15 
'4 reveals that the table layout of HTML page 700 is useful for managing the relative position 

5 and size of the elements of the graphical user interface. 

6 

If ^routine which implements the preferred embodiment of the present invention is depicted 
in the flow chart of Figure 16. The process starts at Block 801, and goes to Block 803, 
wherein the product model is loaded. Next, in accordance with Block 805, the Dialog 
Controls\^odule is loaded. Then, in accordance with Block 807, the Dialog Manager is 
loaded. Next in accordance with Block 809, the Dialog Controls Module is searched for 
the particular product model. Once it is located, the values associated with that particular 
product model are read from the Dialog Controls Module. Then, in accordance with Block 
Jjp 813, the size of the user interface elements are adjusted if necessary in order to have the 
!L5 "cells" sized to an extenrvsufficient to carry all of the text and/or images which are to be 
ffe posted in that particular pohion of the HTML page. This can be best understood with 


#7 reference again to Figure 14.N?or the third row from the top, the text resident in cells 717, 

0 \ 

E3I8 719 may require a greater or lesser amount of space. If these cells need to be expanded, 

19 space that is not dedicated for some^other purpose can be utilized. For example, cells 

20 517, 521 may be further reduced in ordfeMo allow a greater amount of text or images to be 

21 posted to that portion of the HTML page 7^0. Sizing issues may become more complex if 

22 fonts sizes are changed for a particular graphical user interface. Changes in font size will 

23 necessitate recalculation of the available cell space and enlargement of the cells dedicated 

24 for text in order to accommodate the enlarged text. 
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Returning now to Figure 815, once the user interface elements are adjusted in size, then 
the user\ interface is populated with its elements in accordance with Block 815 and the 
process ends at Block 817. 

One principal advantage of the present invention is that existing databases can be utilized 
to populate on HTML pages which serve as graphical user interfaces. This can be done 
without creating any new or separate parallel database for the same types of data. The 
present invention can be applied to a wide variety of programming environments and 
programming languages. The basic concept is to utilize a single data base and multiple 
rendering engines in a controlled manner in order to enable the generation of generally 
similar or comparable graphical user interface environments which utilize that single data 
base to communicate with customers. In this manner, the customer may interact with a 
seller in one programming environment/language on one occasion, but in another 
programming environment/language on another occasion. In all locations, the graphical 
user interface screens which are presented to the user will be generally comparable in 
appearance. Furthermore, the data displayed on those pages will be identical since they 
are drawn or pulled from a single database. 


19 A feature of the present invention is that it can also be applied to multiple sellers, as well 

20 as multiple buyers as described above. This would allow a flexible approach to commerce 

2 1 for complex e-commerce systems. 

22 

23 Although the invention has been described with reference to a particular embodiment, this 

24 description is not meant to be construed in a limiting sense. Various modifications of the 

25 disclosed embodiments as well as alternative embodiments of the invention will become 

26 apparent to persons skilled in the art upon reference to the description of the invention. It 
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is therefore contemplated that the appended clams will cover any such modifications 
embodiments that fall within the scope of the invention. 
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